Update version range for Gson to '[2.9.1,2.11)' #690
Conversation
|
see also #689 |
Yours definitely looks more complete. And 2.10 also just added new methods (see eclipse-m2e/m2e-core#1146 (comment)). So if lsp4j is using gson as consumer and not as provider, the lower can actually stay where it is. If that is wanted it is probably better to update your PR accordingly. And if not yours looks more complete. So either way this can be closed I think. |
|
@jonahgraham reopened due to eclipse-pde/eclipse.pde#482. |
|
@HannesWell is there any documentation on versioning policy on googles side? |
|
Unfortunately not really, no. But this obviously does not apply to gson. |
gradle/versions.gradle
Outdated
| @@ -16,7 +16,7 @@ ext.versions = [ | |||
| 'xtend_lib': '2.28.0', | |||
| 'guava': '[30.1,31)', | |||
| 'guava_orbit': '30.1.0.v20221112-0806', | |||
| 'gson': '[2.10.1,2.11)', | |||
| 'gson': '[2.9.1,2.11)', | |||
| 'gson_orbit': '2.10.1.v20230109-0753', | |||
There was a problem hiding this comment.
Is the value of gson_orbit used? I couldn't find any reference when searching the repo in the GH UI.
There was a problem hiding this comment.
afaik not anymore. just as a reference for the tycho stuff under releng.
There was a problem hiding this comment.
i also expect the other places to be adjusted e.g. feature.xml
There was a problem hiding this comment.
afaik not anymore. just as a reference for the tycho stuff under releng.
OK, removed it. Lets see if the build succeeds.
i also expect the other places to be adjusted e.g. feature.xml
Thanks for the hint. Adjusted the feature too and changed the version rule to compatible to not bind it to gson 2.9.
But I wonder why there is a dedicated dependency for gson in the feature at all?
Since the feature contains org.eclipse.lsp4j already it implicitly requires gson already anyway.
And p2 will consider the version specified in org.eclipse.lsp4j when installing the feature. Therefore this looks like a duplicated information to me. Probably the same for xtend.lib?
In general Feature-dependencies are actually only useful/necessary if none of the included Plug-ins requires it.
|
please note: we at xtext wont be able to build a new release to include this fix for 2023-03 |
HannesWell
force-pushed
the
updateGson
branch
from
bda7f16
to
5358520
Compare
Understand. Does xtext use similar tight version ranges on gson like lsp4j? If not it is hopefully less problematic. |
|
BTW, I expect xtext to be strictly dependent on lsp4j 0.20.0, so a new lsp4j but no new xtext will mean three versions of lsp4j? |
If the version range is very strict and does not even allow a 0.20.1, then yes. :/ I tried it, but didn't find out where exactly xtext depends on lsp4j? @cdietrich can you please clarify in this regard? |
OK. Thank you for pointing this part out as I otherwise would have done a 0.21.0 release. We (LSP4J) haven't done a x.x.1 release in a while, but I can give it a go. |
See eclipse/xtext-core#2019 for xtext tracking issue. It has links to all the code updates needed for LSP4J change. |
I just checked the content metadata in https://download.eclipse.org/modeling/tmf/xtext/updates/releases/2.30.0/ and it shows me that The Plugin Therefore I think a |
|
Yes we would accept a 0.20.1 I guess. also the deps are optional afaik |
|
native question: a lsp4e bump based on the last release with just lsp4j/gson dep. bumped is not an option? |
I cannot tell that. Maybe @laeubi knows in detail? But at least in the p2-world (or Tycho builds based on targets) maven bom's are not considered AFAIK.
I wondered that as well. @mickaelistria would it be? |
|
Yes xtext would accommodate a 0.20.1 version of lsp4j. Is the only thing strictly requiring >= 0.20.0:
If you have snapshot versions of your proposed changes available somewhere I can repeat the analysis. I can even locally build the aggregation and use that to test creating the DSL package, so it would be really great to have snapshot versions (of lsp4j and m2e I guess?) ASAP... |
|
the tycho maven stuff is this one: eclipse/xtext-eclipse#1931 |
|
@merks you can find p2 repo for this pr at https://ci.eclipse.org/lsp4j/job/lsp4j-github-pullrequests/399/artifact/build/p2-repository/ |
Thanks. Btw. is there a reason, why you don't have a dedicated job per PR, for example like in m2e?
That is what I plan to contribute to SimRel for M2E tonight: |
|
i see it for my branches, they are at eclipse/lsp4j, but you pr'ed from your account |
Yes, but the way for example the m2e Jenkins project is set up (I don't know exactly what the infra team did different) and AFAICT for all platform TLP projects, a new job is created for each PR in a dedicated tab, regardless from where the branch is coming. See for example PDE: |
|
That looks better with only features requiring the higher version of gson.
And xtext.ide resolving:
I'll try to build the aggregation locally (with my horrible internet here).... |
|
Woo hoo! The DSL package installed from the aggregated result of the new m2e and this lsp4j version contains only a single version of gson:
Visiting all preference pages which tends to activate all bundles works well too. I will now test the JEE package as well but given it was working fine before I don't expect a problem.... |
It might be good to not include such dependencies in features, they should be pulled in by their using bundle anyways? |
|
Indeed, though often when the platform has tried to remove includes, something stopped working as @akurtakov can confirm. Also, includes are often present because that helps control what's included in the p2 repository; not everyone can or should just include all dependencies, which is a nice and easy solution when you are at the bottom of the food chain and your dependencies tend to be mostly just third party ones... |
|
The JEE package still has two versions:
But none of the exports have been substituted:
So that still looks fine. |
|
I think we addressed already a lot of the "something", so I think its worth to try some things (again) e.g. we have now:
So one can use "include all" but still filter items provided from another update-site, and one can include any source if desired (not sure how good this applies to the epp / simrel builds) |
|
FYI, it looks like we are zeroing in on a solution to the gson/lsp4j problem! |
|
Platform issues when removing includes are exactly that things didn't end up in the p2 site so as long as one verifies the proper content is in the p2 site I believe using import is better. |
|
@akurtakov We also ran into strange problems with removing includes from the test feature and we didn't have time to track that down. I totally agree we should try this again during the 4.28 release cycle. It would make updating the target platform much less painful and way less time consuming... |
|
We digress, but this sounds interesting! I found the docs here: It's not entirely clear what a "referenced repository" is but I guess that's a repository referenced from the category.xml; that would indeed be a useful feature... |
|
@merks contributions for better wording are always welcome, developers (at least me) are often the wrong person to write docs because for them everything is "clear from the code" This is how it is used with m2e: |
|
Thanks all for your input and tests. I will ASAP make a 0.20.1 release that contains this change. |
jonahgraham
force-pushed
the
updateGson
branch
from
c56e6a9
to
fef1159
Compare
Thank you Jonah for performing this release. |
I did that already but I hadn't pushed it yet. It is now here in #701 |
Fixes eclipse-lsp4j#702 Backport of eclipse-lsp4j#690 commit ff58da7
As suggested by @jonahgraham in eclipse-m2e/m2e-core#1146 (comment) this updates Gson version range to include the latest Gson releases 2.10 and 2.10.1: